System management operations are frequent in modern data processing systems. Typical system management operations may include distributing and installing new software products, removing old or no more used ones, updating older versions of already installed software products to newer releases, distributing and installing patches solving problems to already installed software applications, and so on.
In distributed data processing systems, forming for example the data processing infrastructures of enterprises, state agencies, institutions of the most disparate nature, which may include very large numbers of terminal computers, system management operations on the several different target computers (also referred to as “endpoints”) of the network are expediently managed in a centralized way, by technically skilled system administrators.
For this purpose, system management software applications have been created and are commercially available that facilitate the centralized system management of the several endpoints that very often make up a distributed data processing system. For example, such system management applications may be or include software package distribution applications that facilitate the deployment of the desired packages of software products from a central site to one or more (possibly all) of the desired endpoints of the network.
An exemplary system management application is the product commercially known as “IBM Tivoli Configuration Manager” (shortly, ITCM), by IBM Corporation.
An aspect of paramount importance in many distributed data processing systems is guaranteeing “business continuity”, which can be defined as ensuring that the data processing system continues to guarantee an at least minimum level of services irrespective the occurrence of critical events.
Guaranteeing business continuity in a distributed data processing system involves in particular ensuring that any software application installed on a certain set of endpoints is maintained at the same release level on all the endpoints of the set; this aspect of business continuity may be referred as “business continuity at the enterprise level”. In fact, a situation wherein a subset of endpoints implements a certain release level, and another subset of endpoints implements a different release level of a same application software is not considered secure from the business continuity viewpoint, because the endpoints implementing different release levels may for example encounter problems when communicating with each other.
Also, in performing system management operations in a centralized way, it is important to avoid doing actions that may impair the system business continuity; this kind of business continuity may be referred to as “business continuity at the endpoint level”. For example, when a certain release of a software application installed on a certain endpoint needs to be upgraded to a newer release, before performing the upgrade it is necessary to ascertain whether that application is currently being executed on that endpoint: in this latter case, since the installation of the upgrade may likely cause an interruption of the activities being performed by that endpoint (for example, an endpoint restart could be needed to successfully complete the upgrade installation, and/or one or more Dynamic Link Libraries—DLLs—which are currently being used and thus locked may have to be replaced during the installation of the upgrade) the upgrade installation operation is better delayed.
Thus, the requisite of business continuity has a strong impact on how the system management operations are to be performed.